Session key distribution methods using a hierarchy of key servers

ABSTRACT

Methods, apparatuses, media and signals for facilitating secure communication between a first device and a second device are disclosed. One method includes automatically identifying a common key server potentially accessible by both the first and second devices, and obtaining a secure private key from the common key server, for use in encrypting communications between the first and second devices. Identifying may include identifying as the common key server, a key server at an intersection of a first communication path defined between a first key server having a previously established relationship with the first device and a master key server, and a second communication path defined between a second key server having a previously established relationship with the second device and the master key server. Obtaining may include obtaining a plurality of private keys and blending the keys to produce a final private session key.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of priority from U.S. patentapplication Ser. No. 60/364,621 filed Mar. 18, 2002.

BACKGROUND OF THE INVENTION

1. Field of Invention

The present invention relates to communications, and more particularly,to methods, apparatuses, media, signals and computer program productsfor facilitating secure communications between a first device and asecond device:

2. Description of Related Art

It is often desirable to have secure communications between first andsecond devices. For example, the devices may include respective desktop,laptop or handheld computers, in communication with each other over apublic network such as the Internet. It is frequently desirable to allowthese devices to transmit sensitive information securely to one anotherover the Internet, without significant risk of interception byunauthorized eavesdroppers. In many instances, it is desirable toattempt to arrange secure communication between the first and seconddevices, even if the first and second devices have never previouslycommunicated with each other before. For example, a patent attorney orother lawyer may wish to communicate sensitive secret client informationto a new client over the Internet, but may wish to minimize the risk ofunauthorized interception of such information. Or, as a further example,a purchaser may wish to transmit sensitive payment account informationsuch as credit card information to a vendor over the Internet.

Numerous conventional secure communications methods exist. The methodsthat are most commonly used over the Internet at present (such as SSL)employ an infrastructure based upon asymmetric encryption. In asymmetricencryption, two keys are used: a private key that is kept secret orprivate, and a public key that is accessible by every computer on theInternet. However, the current asymmetric encryption methods (as do anyother secure communications methods) have potential inherent securityrisks that may be exploitable. Such risks may be partly addressed bysymmetrical encryption methods, wherein only a single symmetrical key(referred to herein as a private key) is used, and key distributionschemes are adopted to attempt to securely provide the private key tothe parties that wish to communicate.

A number of key distribution schemes have been proposed to attempt toprovide two users or clients with a private key for communicationtherebetween. However, these schemes tend to presume that both of thetwo clients already have pre-existing relationships with the sametrusted intermediary server, and have previously exchanged mutual keyswith the server to allow them to establish secure communications withthe trusted intermediary server. Such schemes also tend to presume thateach of the two users is also aware that both users have pre-existingrelationships with the trusted intermediary, and that the trustedintermediary in question is therefore a suitable server to select forexecution of the key distribution scheme. In many cases, however,particularly where two users are in communication with each other via alarge public wide area network such as the Internet, neither of the twousers will have any knowledge of the other's pre-existing relationshipswith key servers, and indeed, many unsophisticated computer users maynot have any knowledge of their own pre-existing relationships with keyservers. Thus, even if a trusted intermediary with pre-existingrelationships with both users exists, the users may not be aware of thisfact and may not know to select the trusted intermediary for thispurpose. In addition, in many cases the group of key servers with whichone user has pre-existing relationships will not include any of the keyservers with which the other user has pre-existing relationships, withthe result that a trusted intermediary is not available to participatein the key distribution scheme. These problems would tend to ariseunless mutual keys had been pre-established at both a client-serverlevel and a server-server level over all domains, which would not bepractical for a large network such as the Internet that includes a verylarge number of domains.

Accordingly, there is a need for an improved secure communicationsmethod.

SUMMARY OF THE INVENTION

In accordance with another aspect of the invention, there is provided amethod of facilitating secure communication between first and seconddevices. The method includes automatically identifying a common keyserver potentially accessible by both the first and second devices, andobtaining a secure private key from the common key server, for use inencrypting communications between the first and second devices.

Advantageously, as the method includes automatically identifying acommon key server potentially accessible by both the first and seconddevices, it is not necessary for the first and second devices to knowthe identity of the common key server in advance, nor is it necessaryfor them to have previously exchanged mutual keys with the common keyserver. It is sufficient for the first and second devices to know thatthey wish to communicate securely with each other, and for each of thedevices to have a parent key server (not necessarily the same keyserver). In addition, as a private key is obtained for encryptionpurposes, the method is not susceptible to potentially exploitablesecurity weaknesses associated with asymmetric encryption.

Identifying the common key server may include transmittingidentifications of key servers from one of the first and second devicesto the other of the first and second devices. Identifying may furtherinclude producing a first list of key servers potentially accessible bythe first device.

Producing may include including in the first list, identifications ofkey servers associated with first device keys stored in a storage mediumof the first device. Producing may further include including in thefirst list, identifications of intermediate key servers interposed alongsecure communications paths between each of the key servers associatedwith the first device keys and a master key server.

Transmitting may include transmitting the first list from the firstdevice to the second device. Identifying may further include receivingat the first device, from the second device, an identification of thecommon key server.

Identifying may include receiving at the second device, a first list ofkey servers potentially accessible by the first device. Identifying mayfurther include producing a second list of key servers potentiallyaccessible by the second device. Producing may include including in thesecond list, identifications of key servers associated with seconddevice keys stored in a storage medium of the second device. Producingmay further include including in the second list, identifications ofintermediate key servers interposed along secure communications pathsbetween each of the key servers associated with the second device keysand a master key server.

Identifying may further include comparing the first and second lists,and identifying, as the common key server, a key server identified inboth lists.

Identifying may include identifying as the common key server, from amonga group of key servers each of which is identified in both the first andsecond lists, the key server having the shortest communications paths tothe first and second devices. Advantageously therefore, in suchembodiments, the time required to obtain the private key is potentiallyreduced in comparison to systems that always rely on a single keyserver.

Identifying may include identifying as the common key server, a keyserver at an intersection of a first communication path defined betweena first key server having a previously established relationship with thefirst device and a master key server, and a second communication pathdefined between a second key server having a previously establishedrelationship with the second device and the master key server.Advantageously therefore, in such embodiments, it is not necessary forthe first and second devices to have a previously-establishedrelationship with the same, single trusted intermediary in order toestablish secure communications between themselves.

Transmitting may include transmitting, from the second device to thefirst device, an identification of the common key server. Transmittingmay further include transmitting, from the second device to the firstdevice, identifications of any intermediate key servers interposedbetween the first device and the common key server.

Identifying may further include identifying intermediate key serversinterposed along a communications path between one of the first andsecond devices and the common key server. Obtaining may includeobtaining the private key from one of the intermediate key servers thathas received the private key from the common key server.

Obtaining may include receiving the private key from the common keyserver via a secure communications channel. Receiving may includereceiving the private key from an intermediate key server that hasreceived the private key from the common key server.

Obtaining may further include transmitting a request message to thecommon key server to request the common key server to transmit theprivate key. Transmitting may include transmitting the request messageto an intermediate key server, for relay to the common key server.

The method may further include validating the private key. Validatingmay include receiving a first hash value produced by the common keyserver in response to the private key, generating a second hash value inresponse to the received private key, and comparing the first and secondhash values.

Obtaining may include obtaining first and second private keys from atleast one of the common key server and a second common key serverpotentially accessible by both the first and second devices. Obtainingfirst and second private keys may include obtaining a private user keyfrom a common user key server and a private device key from a commondevice key server.

The method may further include obtaining an initial session key.Obtaining the initial session key may include receiving the initialsession key at the first device. Alternatively, from the perspective ofthe second device, obtaining the initial session key may includegenerating the initial session key at the second device and transmittingthe initial session key to the first device.

The method may further include encrypting communications between thefirst and second devices, in response to the private key. In embodimentswhere first and second private keys are received, this may includeencrypting communications between the first and second devices, inresponse to the first and second private keys. Similarly, in embodimentswhere an initial session key is additionally received, this may includeencrypting communications between the first and second devices, inresponse to the first and second private keys and the initial sessionkey. Encrypting may include blending the first and second private keysand the initial session key to produce a modified key.

Blending may include encrypting at least one of the first and secondprivate keys and the initial session key using at least one other of thefirst and second private keys and the initial session key. For example,blending may include encrypting the first private key using the secondprivate key to produce a once-encrypted key. Similarly, blending mayfurther include encrypting the once-encrypted key using the initialsession key to produce a twice-encrypted key. Blending may furtherinclude generating a hash value in response to the twice-encrypted key,and appending the hash value to the twice-encrypted key. Blending mayfurther include deleting a portion of the twice-encrypted key other thanthe hash value appended thereto, the deleted portion having a lengthequal to the hash value appended thereto. Blending may further includerepeating the steps of generating and appending a hash value to thetwice-encrypted key and deleting a portion of the twice-encrypted keyuntil the twice-encrypted key has been entirely replaced with appendedhash values. Advantageously, in such embodiments, the final privatesession key so generated is a truly private key, with no correspondingroot keys stored in a software program or on the device or on a publiclyaccessible key server. As the final private session key has not beendirectly transmitted over the Internet (or other network) at all, and nodevices other than the first and second devices have all the datanecessary to create the final private session key, security isconsiderably enhanced as compared to conventional secure communicationssystems.

More generally, if desired, encrypting may include encryptingcommunications between the first and second devices using a blended keyproduced in response to the private key.

Encrypting may include initiating a cipher communications session withthe blended key. Initiating may include executing a modified ARC4streaming cipher communications session. Executing may include repeatinga shuffling loop of the ARC4 streaming cipher communications session, aprime number of times greater than two.

In accordance with another aspect of the invention, there is provided anapparatus for facilitating secure communication between first and seconddevices. The apparatus includes a processor circuit capable ofcommunication with a network. The processor circuit is configured toidentify a common key server potentially accessible by both the firstand second devices. The processor circuit is also configured to obtain asecure private key from the common key server, for use in encryptingcommunications between the first and second devices.

The processor circuit may be configured to carry out the various methodsdisclosed herein.

In accordance with another aspect of the invention, there is provided anapparatus for facilitating secure communication between first and seconddevices. The apparatus includes means for identifying a common keyserver potentially accessible by both the first and second devices. Theapparatus further includes means for obtaining a secure private key fromthe common key server, for use in encrypting communications between thefirst and second devices.

The apparatus may further include means for performing the variousfunctions disclosed herein.

In accordance with another aspect of the invention, there is provided amethod of facilitating secure communications between first and seconddevices. The method includes receiving, at an intermediate key server, arequest message from one of the first and second devices requesting aprivate key. The method further includes relaying the request message toa common key server potentially accessible by both the first and seconddevices. Similarly, in accordance with another aspect of the invention,there is provided an apparatus for facilitating secure communicationsbetween first and second devices. The apparatus includes an intermediatekey server, including a processor circuit configured to carry out theabove method. In accordance with another aspect of the invention, thereis provided an apparatus including an intermediate key server. Theintermediate key server includes means for performing the abovefunctions.

In accordance with another aspect of the invention, there is provided amethod of facilitating secure communications between first and seconddevices. The method includes receiving, at a common key serverpotentially accessible by both the first and second devices, requestmessages from first and second intermediate servers interposed betweenthe common key server and the first and second devices respectively,requesting a private key. The method further includes generating andtransmitting the private key to the first and second intermediateservers in response to the request messages, for relay to the first andsecond devices. Similarly, in accordance with another aspect of theinvention, there is provided an apparatus for facilitating securecommunications between first and second devices. The apparatus includesa common key server potentially accessible by both the first and seconddevices. The common key server includes a processor circuit configuredto carry out the above method. In accordance with another aspect of theinvention, there is provided an apparatus including a common key serverpotentially accessible by both the first and second devices. The commonkey server includes means for performing each of the above functions.

In accordance with another aspect of the invention, there is provided acomputer program including code means that when executed on a computercarry out all the steps of any of the methods disclosed herein.Similarly, in accordance with another aspect of the invention, there isprovided a computer program on a carrier carrying codes that whenexecuted on a computer carry out all the steps of any of the methodsdisclosed herein. In accordance with another aspect of the invention,there is provided a computer-readable medium storing code segments fordirecting a processor circuit to carry out any of the methods disclosedherein. In accordance with another aspect of the invention, there isprovided a signal embodied in a communications medium, the signalincluding code segments for directing a processor circuit to carry outany of the methods disclosed herein. In accordance with another aspectof the invention, there is provided a signal embodied in a carrier wave,the signal including code segments for directing a processor circuit tocarry out any of the methods disclosed herein.

Other aspects and features of the present invention will become apparentto those ordinarily skilled in the art upon review of the followingdescription of specific embodiments of the invention in conjunction withthe accompanying figures.

BRIEF DESCRIPTION OF THE DRAWINGS

In drawings which illustrate embodiments of the invention,

FIG. 1 is a block diagram of a public network in which a plurality ofuser devices is in communication with a plurality of key servers;

FIG. 2 is a block diagram of an apparatus for facilitating securecommunication between first and second devices shown in FIG. 1,according to a first embodiment of the invention;

FIG. 3 is a signal flow diagram illustrating signal flow among thedevices and servers shown in FIG. 1;

FIGS. 4A-4B are a flowchart of a messaging thread executed by aprocessor circuit of the apparatus shown in FIG. 2; and

FIGS. 5-11 are tabular representations of various signals shown in FIG.3.

DETAILED DESCRIPTION

Referring to FIG. 1, an apparatus for facilitating secure communicationbetween first and second devices according to a first embodiment of theinvention is shown generally at 20. In this embodiment, the apparatus 20includes a processor circuit 50 capable of communication with a network.The processor circuit is configured to identify a common key server 32potentially accessible by both a first device 26 and a second device 28.The processor circuit 50 is configured to obtain a secure private keyfrom the common key server 32, for use in encrypting communicationsbetween the first and second devices 26 and 28. In this embodiment, theterm “accessible” does not require direct accessibility, but can alsoinclude indirect accessibility, and therefore does not imply thenecessity of any previously established direct relationship between thefirst device and the common key server, nor between the second deviceand the common key server.

In this embodiment, the processor circuit 50 is housed within the firstdevice 26. In the present embodiment, the second device 28 also includesa processor circuit 51 similar to the processor circuit 50. Like theprocessor circuit 50 of the first device 26, the processor circuit 51 ofthe second device 28 is also configured to identify the common keyserver potentially accessible by both devices, and to obtain a secureprivate key from the common key server for use in encryptingcommunications.

Referring to FIGS. 1 and 2, in this embodiment, the first and seconddevices 26 and 28 are merely two illustrative examples of a largerplurality of user devices 24. Each of the plurality of user devices 24is capable of communication with each other and with one or more of aplurality of key servers shown generally at 22 via a public network 44,which in this embodiment includes the Internet.

In the present embodiment, the first device 26 and the second device 28include respective desktop computers. Alternatively, however, the firstand second devices may include personal communication devices. Forexample, the first and second devices may include personal computingdevices, such as desktop or laptop computers, or may include handheldcomputing devices such as handheld computers or e-mail devices, forexample. Alternatively, however, the first and second devices need notinclude user or client devices, but may alternatively include otherdevices such as servers, for example, or more generally, may include anyother suitable type of communications devices.

In this embodiment, the first and second devices 26 and 28 wish toestablish a secure communication connection therebetween, but have notsecurely communicated with one another previously, and neither devicehas any advance knowledge of the identities of any key servers that maybe available to the other device. More particularly, the first andsecond devices 26 and 28 wish to establish a direct communicationsconnection that does not suffer from security weaknesses associated withconventional secure communications methods, for transmission ofparticularly sensitive information therebetween. Alternatively, however,the present embodiment may be used equally well between devices thathave securely communicated in the past.

In this embodiment, the key servers 22 may include any suitablecomputing devices capable of executing key server functionality, such asgeneral-purpose or specialized-purpose desktop computers, for example.

In the present embodiment, the key servers 22 include a master keyserver 30, which is capable of secure communications with every otherone of the key servers 22, either directly, or indirectly via one ormore separate secure connections with one or more intermediate keyservers. Thus, in the illustrative example shown in FIG. 1, the keyservers 22 further include a plurality of intermediate key servers, suchas key servers 32, 33 and 34 for example, and a plurality of further keyservers, such as key servers 36, 37, 38, 39, 40, 41 and 42 shown inFIG. 1. Alternatively, it will be appreciated that virtually any numberor relative configuration of key servers may be substituted. Forexample, any key server in the key server “tree” shown in FIG. 1 may actas a “parent” server to any other key server on the tree. Similarly, itwill be appreciated that a much larger number of key servers, includinga much larger number of intermediate key servers between each of thefirst and second devices 26 and 28 and the master key server 30, may bepresent in a particular embodiment, for example.

In this embodiment, each one of the first and second devices 26 and 28has a previously defined relationship with at least one of the keyservers 22, which has previously issued a key to the device and thusacts as a “parent” key server for the device.

More particularly, in the illustrative example shown in FIG. 1, each ofthe key servers 36 and 39 acts as a “parent” key server for the firstdevice 26, and each of the key servers 38 and 42 acts as a “parent” keyserver for the second device 28. Thus, in the present embodiment, itassumed that none of the key servers 22 acts as a “parent” to both thefirst and second devices, or in other words, there is no shared keyserver with which both the first and second devices both havepreviously-defined relationships. In other words, in contrast withconventional private key distribution schemes, in the present embodimentit is assumed that there is no single key server with which both thefirst and second devices have previously established respective keypairs, to allow each of them to securely communicate with the keyserver. Alternatively, however, the present embodiment of the inventionmay also be applied to situations where such a shared key server exists.

Similarly, in the present embodiment, the key server 32 acts as a“parent” to key servers 36, 37 and 38, the key server 33 acts as a“parent” to key servers 39 and 40, and the key server 34 acts as a“parent” to key servers 41 and 42. For illustrative purposes, the keyservers 32, 33 and 34 are therefore referred to as “grandparent” keyservers from the perspective of the first and second devices 26 and 28.The master key server 30 acts as a parent to key servers 32, 33 and 34.

In this embodiment, each of the key servers 22 and the first and seconddevices 26 and 28 is capable of establishing a secure communicationconnection with its own immediate “parent” server, with which it haspreviously established secure communications. For example, in thisembodiment, it is assumed that each device or server was previouslyassigned a user-ID and password to initially communicate with its ownimmediate parent. During this initial communication between each deviceor server and its parent key server, a hash value of the password isused as a session key, to allow the parent to securely transmit aprivate key to the “child” device or server. Once the private key hasbeen initially securely transmitted, the device or server may securelycommunicate with its parent server using the encryption methodsdescribed herein, but without the necessity of obtaining a new privatekey as described below in connection with FIG. 3. Also during theinitial communication between each device or server and its immediateparent key server, the device or server requests its immediate parent totransmit key server path information identifying the path from theimmediate parent key server to the master key server 30. For example,during the initial communication between the first device 26 and theparent key server 39, the parent key server 39 transmits pathinformation to the first device 26, identifying the parent key server39, the grandparent key server 33, and the master key server 30. Uponreceiving this information from the key server 39, the first device 26stores the received path information locally in a hard disk drive orother storage medium thereof, in association with the private keyreceived from the parent key server 39, for future use as describedherein. Similarly, during its initial communication with the parent keyserver 36, the first device 26 receives and stores path informationidentifying the parent key server 36, the closest common key server 32,and the master key server 30, and stores such information locally inassociation with a key associated with the key server 36. Likewise, thesecond device 28, during its initial communication with the parent keyserver 42, receives and stores path information identifying the parentkey server 42, the grandparent key server 34, and the master key server30, and stores this information locally in association with the keyreceived from the parent key server 42. Also in this embodiment, duringits initial communication with the parent key server 38, the seconddevice 28 receives and stores path information identifying the parentkey server 38, the closest common key server 32, and the master keyserver 30, and stores this path information locally in association witha key received from the key server 38. It is assumed that each of theparent key servers 36 through 42 has previously received and locallystored its own upstream path information leading to the master server30, during its own initial communication with its immediate parentserver (such as the grandparent servers 33 and 34 or the common keyserver 32).

Referring to FIGS. 1 and 2, the processor circuit of the first device 26is shown generally at 50 in FIG. 2. In the present embodiment, the firstand second devices 26 and 28 are identical, and thus the processorcircuit 51 of the second device 28 is identical to the processor circuit50 of the first device 26 shown in FIG. 2. Thus, for ease ofillustration, only the processor circuit 50 is described in detail, itbeing understood that the processor circuit 51 includes similarstructural and functional features. Alternatively, as noted above, thefirst and second devices may include different types of devices ifdesired.

Similarly, in this embodiment, each of the key servers 22 shown in FIG.1 has a processor circuit similar to the processor circuit 50, such as aprocessor circuit 132 of the common key server 32, a processor circuit136 of the key server 36, and a processor circuit 138 of the key server38, for example. If desired, these processor circuits may also becapable of the full functionality of the processor circuit 50 describedbelow. Alternatively, however, as will be apparent, for the purposes ofthe present embodiment of the invention, the key servers 22 do notrequire the full range of functionality provided by the securecommunications routine 62, but rather, may be provided with analternative routine to merely direct their respective processor circuitsto receive and respond to signals as discussed below.

In this embodiment, the processor circuit 50 includes a microprocessor52. More generally, however, in this specification, the term “processorcircuit” is intended to broadly encompass any type of device orcombination of devices capable of performing the functions describedherein, including (without limitation) other types of microprocessors,microcontrollers, other integrated circuits, other types of circuits orcombinations of circuits, logic gates or gate arrays, or programmabledevices of any sort, for example, either alone or in combination withother such devices located at the same location or remotely from eachother, for example. Additional types of processor circuits will beapparent to those ordinarily skilled in the art upon review of thisspecification, and substitution of any such other types of processorcircuits is considered not to depart from the scope of the presentinvention as defined by the claims appended hereto.

In the present embodiment, the microprocessor 52 is in communicationwith a first computer readable medium, which in this embodiment includesa hard disk drive 54. The microprocessor 52 is in further communicationwith a second computer readable medium, which in this embodimentincludes a random access memory (RAM) 56. The microprocessor 52 is infurther communication with an input/output (I/O) interface 58, throughwhich the microprocessor communicates with the various key servers 22and other user devices 24, via the public network 44. Also in thisembodiment, the microprocessor 52 is in communication with a mediainterface device 53, to allow the microprocessor 52 to read data from orwrite data to other types of computer readable media, such as a compactdisc 55 or a floppy diskette 57, for example. If desired, themicroprocessor may be in further communication with other types ofcomputer readable media, such as magnetic disks or diskettes, opticalstorage devices, magnetic tapes, random access memories (RAMs),programmable read-only memories such as EPROMs, EEPROMs or FLASHmemories, for example, or any other type of memory device, either at thelocation of the processor circuit or located remotely therefrom, forexample.

In this embodiment, the hard disk drive 54 acts as a program memory forstoring various routines executable by the processor circuit 50.Alternatively, however, it will be appreciated that the hard disk drive54 is merely one example of a computer-readable medium for storing suchroutines. More generally, any other suitable type of medium, such asthose noted above or others for example, or any other suitable way ofgenerating a signal such as that shown at 59 including code segments fordirecting the microprocessor 52 to carry out the functions describedherein, may be substituted. Such a signal may be embodied in acommunications medium, such as a data bus or other link to the network44, or a carrier wave for example, and thus, the routines may beprovided as downloaded applets or other executable instructions receivedfrom a remote source, if desired.

In the present embodiment, the routines stored on the hard disk drive 54executable by the processor circuit 50 include an operating system 60, asecure communications routine 62, and various user applications 64. Inthis embodiment, the secure communications routine 62 includes a dynamiclink library for directing the processor circuit to execute a number ofthreads, including a messaging thread 66, an encryption/decryptionthread 68, a pipe control/TCP send thread 70, a TCP receive thread 72, akey server thread 74, and a data object monitor thread 76. If desired,multiple instances of such threads may be defined and executed by theprocessor circuit. In this embodiment, the secure communications routine62 further includes a threadsafe function 80 that the processor circuitmay invoke under the direction of any of the various threads, to ensureproper handling of shared data space such as shared data buffers orregisters and fields therein, for example.

When executed by the processor circuit 50, the secure communicationsroutine 62 configures or programs the processor circuit to definevarious registers in the RAM 56, including a user-ID list register 90, adevice-ID list register 92, a user-ID paths register 94, a device-IDpaths register 96, an initial session key register 98, a private keysregister 100, a blended key register 102, and a final private sessionkey register 104. Similarly, the secure communications routine 62configures the processor circuit to define various buffers for use insecure encrypted communications, including a send buffer 110, a key sendbuffer 112, a pipe send buffer 114, a pipeline control buffer 116, a keyreceive buffer 120, and a receive buffer 122.

It will be appreciated that numerous other registers and buffers maysimilarly be defined and used by the processor circuit under thedirection of the secure communications routine 62.

In this embodiment, the user applications 64 do not interface directlywith the TCP/IP functionality of the operating system 60. Rather, theuser applications 64 interface with the secure communications routine62, which establishes and handles all TCP/IP communications. Tofacilitate this interface with the user applications 64, in the presentembodiment the secure communications routine 62 is provided in the formof a dynamic link library (.dll) file, which in this embodiment requiresapproximately 150 kB of storage space in the hard disk drive 54. In thisembodiment, although the secure communications routine 62 is describedbelow as having a single set of threads for illustrative purposes, moregenerally, the secure communications routine 62 of the presentembodiment is multithreaded. For example, if a particular userapplication creates a plurality of client objects, each client objectwill have its own corresponding set of threads for its own respectivesecure communications session. Similarly, if the first device is actingas a server, with a plurality of connected clients, a separate set ofthreads will be executed for each client. All such multithreading occurstransparently to the user application, which need not be multithreadeditself, and need not synchronize the various sets of threads.

In a particular embodiment, if the operating system 60 includes aWindows operating system, it may be preferable for Windows MessageNotificafion for TCP to be deactivated. In a Windows environment, thesend and receive operations of TCP are preferably in endless loops, andexit only if the communications session collapses. Other potential exittriggers, such as timeouts, are preferably disabled, as some timeoutsmay occur in certain embodiments if particular buffers temporarily fill.

Messaging Thread

Referring to FIGS. 1 to 11, the messaging thread is shown generally at66 in FIGS. 4A-4B. Generally, the messaging thread 66 configures orprograms the processor circuit 50 to automatically identify a common keyserver potentially accessible by both the first and second devices 26and 28, and to obtain a secure private key from the common key server,for use in encrypting communications between the first and seconddevices.

In the present embodiment, to identify the common key server and obtainthe secure private key, the messaging thread 66 configures the processorcircuit 50 to participate in a signal flow shown generally at 500 inFIG. 3.

Referring to FIGS. 1 to 4B, the messaging thread 66 begins with a firstblock 200 of codes shown in FIG. 4A, which directs the processor circuit50 of the first device 26 to determine whether one of the userapplications 64 being executed by the processor circuit 50 has requestedthe messaging thread 66 to initiate secure communications with anotherdevice, which is assumed for illustrative purposes to be the seconddevice 28. If so, the processor circuit 50 is directed to execute blocks202 to 208. If no such request to initiate communications has beenreceived, the processor circuit is directed to determine whether arequest for secure communications has been received from the seconddevice 28 at the first device 26. If so, the processor circuit isdirected to execute blocks 212 through 222.

In the present description of the messaging thread 66, for illustrativepurposes, it is assumed that the first device 26 initiatescommunications with the second device 28, and thus the processor circuit50 of the first device executes blocks 202 to 208 in FIG. 4A. Therefore,it is assumed that the second device 28 responds to the communicationsinitiation request, and that the processor circuit 51 of the seconddevice executes blocks 212 through 222. Alternatively, however, thesecond device 28 may initiate communications if desired, in which casethe processor circuit 51 may execute blocks 202 to 208 and the processorcircuit 50 may execute blocks 212 through 222. For illustrative purposesonly, in the following description, the term “first device” is used toindicate the device initiating communications, and the term “seconddevice” is used to indicate the device responding to the communicationsinitiation request.

Accordingly, in the present illustrative example, to initiate securecommunications between the first device 26 and the second device 28,blocks 202 to 206 of the messaging thread 66 direct the processorcircuit 50 to transmit identifications of key servers from the firstdevice to the second device. More particularly, blocks 202 and 204direct the processor circuit 50 to produce a first list of key serverspotentially accessible by the first device. Blocks 202 and 204 directthe processor circuit 50 to include in the first list, identificationsof key servers associated with first device keys stored in a storagemedium of the first device. More particularly still, in this embodimentblock 202 directs the processor circuit 50 to examine the contents ofthe hard disk drive 54, and identify all device keys (associated withthe particular device 26, regardless of the user using the device) anduser keys (associated with the user of the device 26, no matter whatdevice the user is using) used by the first device 26. Block 204 directsthe processor circuit 50 to produce and store a user-ID list and adevice-ID list, in the user-ID list register 90 and the device-ID listregister 92, respectively, each list including a server path for eachidentified user or device key, respectively.

Referring to FIGS. 1, 2, 4A and 5, in this embodiment, block 204 furtherconfigures the processor circuit 50 to include in the first list,identifications of intermediate key servers interposed along securecommunications paths between each of the key servers associated with thefirst device keys and a master key server. This is performed for each ofthe user-ID list and the device-ID list. More particularly, in thisembodiment the processor circuit 50 is directed to store, in the user-IDlist register 90, a first user-ID path 502 representing a server pathcorresponding to a default or preferred user-ID, and a plurality ofadditional or alternative user-ID paths 504. Each of the server paths502 and 504 includes a name field 506 for storing a user name, a first“parent” key server field 508 for storing an identification of a firstkey server associated with the key, and a plurality of further keyserver fields 510, for storing identifications of all intervening keyservers along a secure path leading to and including the master keyserver 30 shown in FIG. 1. For example, in the example shown in FIG. 1,the first device 26 uses a user-ID key associated with the key server36, and thus, the relevant user-ID list entry includes a user namecorresponding to the key, an identification of the key server 36, anidentification of the common key server 32, and an identification of themaster key server 30. In this regard, it will be recalled that duringits prior initial communication with the key server 36 in which itobtained the user-ID key, the first device 26 will have received andlocally stored path information identifying the key server path from thekey server 36 to the master key server 30, which in this exampleincludes identifications of the key server 36, an intermediate server,namely, the closest common key server 32, and the master key server 30itself. In the present embodiment, during such prior initialcommunication with the key server 36, the first device receives andstores such information locally, in the hard disk drive 54, inassociation with the user-ID key associated with the key server 36.Thus, block 204 directs the processor circuit 50 to locate such pathinformation stored in the hard disk drive 54 in association with therelevant user-ID key, and to copy the identifications of the key serversidentified in the stored path information into the appropriate fields508 and 510 of the relevant record in the user-ID list register 90corresponding to the particular user-ID key. Alternatively, if desired,rather than relying upon the previously locally stored key serverinformation, block 204 may direct the processor circuit 50 to signal theimmediate parent key servers associated with each locally stored key (inthe present example, the key server 36), and to request that the keyserver transmit updated key server path information to the first device26. Similarly, the immediate parent key server may respond to such arequest by either transmitting locally stored key server pathinformation, or by requesting its

own parent key server to provide updated key server path information.Generally, it is preferable to rely upon previously stored key serverpath information and update only occasionally, in order to minimizecommunications traffic associated with the key distribution processdescribed herein.

Similarly, referring to FIGS. 1, 2, 4A and 6, block 204 directs theprocessor circuit to store, in the device-ID list register 92, a firstdevice-ID path 512 representing a server path corresponding to a defaultor preferred device-ID, and a plurality of additional or alternativedevice-ID paths 514. Each of the server paths 512 and 514 includes aname field 516 for storing a device name, a first “parent” key serverfield 518 for storing an identification of a first key server associatedwith the key, and a plurality of further key server fields 520, forstoring identifications of all intervening key servers along a securepath leading to and including the master key server 30 shown in FIG. 1.

Referring to FIGS. 1, 2, 3, 4A, 5 and 6, in this embodiment block 206then directs the processor circuit 50 to transmit the first list, ormore particularly, the user-ID list and the device-ID list, from thefirst device 26 to the second device 28. More particularly, block 206directs the processor circuit 50 of the first device 26 to transmit, tothe second device 28, a signal 530 shown in FIG. 3. In this embodiment,the signal 530 includes the contents of the user-ID list register 90shown in FIG. 5, and the contents of the device-ID list register 92shown in FIG. 6. As a secure communications connection has not beenestablished between the first and second devices 26 and 28, the signal530 is transmitted to the second device 28 in a non-secure manner, overthe Internet.

Referring to FIGS. 1, 2, 3, 4A, 5 and 6, as discussed above, it will beappreciated that another instance of the messaging thread 66 is beingexecuted by the processor circuit 51 of the second device 28. Uponreceiving the signal 530, block 210 of the messaging thread 66 directsthe processor circuit 51 to block 212 shown in FIG. 4A, which directsthe processor circuit 51 to receive at the second device, a first listof key servers potentially accessible by the first device. Moreparticularly, block 210 directs the processor circuit 51 to receive andstore the contents of the signal 530, including the contents of theuser-ID list register 90 and the device-ID list register 92.

Blocks 214 and 216 then direct the processor circuit 51 of the seconddevice to produce a second list of key servers potentially accessible bythe second device, and to include in the second list, identifications ofkey servers associated with second device keys stored in a storagemedium of the second device. Block 216 directs the processor circuit 51to include in the second list, identifications of intermediate keyservers interposed along secure communications paths between each of thekey servers associated with the second device keys and a master keyserver. To achieve this, blocks 214 and 216 direct the processor circuit51 to examine its own hard disk drive or other storage medium, toidentify all user keys and device keys used by the second device 28, andto locally store user-ID and device-ID key server path informationsimilar to that shown in FIGS. 5 and 6, in a manner similar to thatdiscussed above in connection with blocks 202 and 204.

Block 218 then directs the processor circuit 51 of the second device 28to compare the first and second lists, and identify, as the common keyserver, a key server identified in both lists. Generally, in thisembodiment block 218 configures the processor circuit 51 to identify asthe common key server, from among a group of key servers each of whichis identified in both the first and second lists, the key server havingthe shortest communications paths to the first and second devices. Moreparticularly, block 218 configures the processor circuit 51 to identifyas the common key server, a key server at an intersection of a firstcommunication path defined between a first key server having apreviously established relationship with the first device and a masterkey server, and a second communication path defined between a second keyserver having a previously established relationship with the seconddevice and the master key server. This is carried out separately forboth the first and second user-ID lists for the first and seconddevices, and for the first and second device-ID lists for the first andsecond devices. To achieve this, block 218 directs the processor circuitto compare the user and device-ID lists of the first and second devices,and to identify a closest common user-ID key server and a closest commondevice-ID key server, that appear in the respective user-ID lists anddevice-ID lists of both the first and second devices. For example, inthe illustrative example shown in FIG. 1, the second device 28 uses auser-ID key associated with the key server 38, which follows a keyserver path through the common key server 32 to the master key server30, and also uses another user-ID key associated with the key server 42,which follows a key server path through the key server 34 to the masterkey server 30. It will be recalled that the first device 26 has auser-ID key associated with the key server 36, which follows a keyserver path through the common key server 32 to the master key server30. Thus, in this example, the closest common user-ID key server is thecommon key server 32. (There will always be at least one common keyserver, namely, the master key server 30, however, in many cases acloser common key server, such as the common key server 32 in thepresent example, will be present.)

Referring to FIGS. 1, 2, 3, 4A and 7, after identifying the closestcommon user-ID key server and the closest common device-ID server, block220 directs the processor circuit 51 of the second device 28 to obtainan initial session key. More particularly, block 220 directs theprocessor circuit 51 to generate the initial session key at the seconddevice, and store it in the local initial session key register (similarto the initial session key register 98 at the first device 26). Moreparticularly still, in this embodiment block 220 directs the processorcircuit 51 to generate an 8-kilobit key for use as the initial sessionkey.

In this embodiment, block 222 then directs the processor circuit 51 totransmit, from the second device 28 to the first device 26, anidentification of the common key server. Block 222 also directs theprocessor circuit 51 to transmit, from the second device to the firstdevice, identifications of any intermediate key servers interposedbetween the first device and the common key server. In the presentembodiment, block 222 also directs the processor circuit 51 to transmitthe initial session key to the first device. To achieve this, block 222directs the processor circuit 51 of the second device to generate andtransmit a signal 540 to the first device 26. As a secure communicationsconnection has not been established between the first and second devices26 and 28, the signal 540 is transmitted to the first device 26 via anon-secure Internet connection established in connection withtransmission of the signal 530 discussed above. In this embodiment, thesignal 540 includes a first device user-ID path field 542, a seconddevice user-ID path field 544, a first device device-ID path field 546,a second device device-ID path field 548, and an initial session keyfield 550. The first device user-ID path field 542 stores pathinformation from the first device 26 to the closest common user-ID keyserver. To produce the first device user-ID path field 542 contents, theprocessor circuit 51 of the second device locates the relevant serverpath record from the user-ID list received from the first device 26(i.e., a record containing an identification of the common key server32), but truncates this server path information at the closest commonuser-ID key server, so that the last sub-field in the first deviceuser-ID path field 542 is a common key server sub-field 543 identifyingthe closest common user-ID key server, which in this example is thecommon key server 32. The second device user-ID path field 544 includespath information identifying the path that the second device 28 will useto communicate with the closest common user-ID key server. Thus, in theexample shown in FIG. 1, the second device user-ID path field 544includes a user-ID sub-field, a first parent server sub-fieldidentifying the key server 38, and a final server sub-field indicatingthe common key server 32. The fields 546 and 548 include analogousinformation, corresponding to the paths that the first and seconddevices will respectively use to communicate with the closest commondevice-ID key server (which may or may not be the same as the closestcommon user-ID key server). Effectively, therefore, the processorcircuit 51 is configured to identify intermediate key servers interposedalong a communications path between one of the first and second devicesand the common key server, the identifications being stored in thefields 542, 544, 546 and 548. Finally, the initial session key field 550includes the 8 kilobit initial session key generated by the processorcircuit 51 of the second device 28 under the direction of block 220above, for use in key-blending, as discussed below. In addition totransmitting the signal 540 to the first device 26, the processorcircuit of the second device also stores all of the informationcontained in the signal 540 locally at the second device 28.

Following execution of block 222, the processor circuit 51 of the seconddevice 28 is directed to block 224 of the messaging thread 66 shown inFIG. 4B, as discussed below in connection with the processor circuit 50of the first device 26.

Referring to FIGS. 1, 2, 3, 4A and 7, block 208 then configures theprocessor circuit 50 of the first device 26 to receive at the firstdevice, from the second device, an identification of the common keyserver. Block 208 also configures the processor circuit 50 to obtain aninitial session key, by receiving the initial session key generated bythe processor circuit 51 of the second device 28. To achieve the above,block 208 directs the processor circuit 50 to receive the signal 540,and store its contents in the RAM 56. More particularly, the processorcircuit 50 stores the contents of the first device user-ID path field542, the second device user-ID path field 544, the first devicedevice-ID path field 546, the second device device-ID path field 548,and the initial session key field 550, in a first device sub-field ofthe user-ID paths register 94, a second device sub-field of the user-IDpaths register 94, a first device sub-field of the device-ID pathsregister 96, a second device sub-field of the device-ID paths register96, and the initial session key register 98, respectively.

Following execution of block 208, the processor circuit 50 of the firstdevice 26 is directed to block 224 of the messaging thread 66 shown inFIG. 4B, as discussed below.

Referring to FIGS. 1, 2, 3 and 4B, in this embodiment, both theprocessor circuit 50 of the first device 26 and the processor circuit 51of the second device 28 proceed to execute blocks 224 through 236 of themessaging thread 66, to obtain a secure private key for use inencrypting communications between the first and second devices.Generally, blocks 224 through 236 configure each of the processorcircuits 50 and 51 to obtain first and second private keys from at leastone of the common key server and a second common key server potentiallyaccessible by both the first and second devices. More particularly, inthis embodiment each of the processor circuits 50 and 51 is configuredto obtain, as the first and second private keys, a private user key froma common user key server and a private device key from a common devicekey server. In this embodiment, the common user key server and thecommon device key server are the closest common user-ID key server andthe closest common device-ID key server respectively, as identifiedabove at block 218 (it will be recalled that these may be the same or adifferent server). To achieve this, blocks 224 through 236 configure theprocessor circuits 50 and 51 to use the key server path informationcontained in the signal 540, to cause two private session keys, namely,a user private session key and a device private session key, to begenerated and securely transmitted by the closest common user-ID keyserver and by the closest common device-ID key server, respectively.Thus, referring to FIGS. 1, 2, 3, 4B, 7, 8 and 9, the first and seconddevices 26 and 28 contemporaneously transmit private key generationrequests to their respective user-ID and device-ID key servers.

In this embodiment, block 224 configures the processor circuit 50 totransmit a request message to the common key server 32, to request thecommon key server to transmit the private key. More particularly, block224 directs the processor circuit 50 to transmit the request message toan intermediate key server, for relay to the common key server. Moreparticularly still, block 224 directs the processor circuit 50 totransmit a signal 560 to the first “parent” server identified in thefirst device sub-field of the user-ID paths register 94 (it will berecalled that the contents of this sub-field are identical to thecontents of the first device user-ID path field 542 shown in Figure 7).Thus, in the example shown in FIG. 1, the first device 26 transmits thesignal 560 to the key server 36. The signal 560 specifies the respectivekey server paths that the first device 26 and the second device 28 wishto use to respectively communicate with the common key server 32identified last in each such path. More particularly, the signal 560includes a first device field 562 having contents identical to those ofthe first device sub-field of the user-ID paths register 94, and asecond device field 564 having contents identical to those of the seconddevice sub-field of the user-ID paths register 94. The signal 560 istransmitted in a secure manner to the key server 36, via a secureconnection established using a key corresponding to the key server pathinformation contained in the first device sub-field of the user-ID pathsregister 94.

Similarly, to request a device private session key, block 224 alsodirects the processor circuit 50 of the first device 26 to transmit ananalogous signal shown generally at 566 in FIG. 9, to the first “parent”server identified in the first device sub-field of the device-ID pathsregister 96 (it will be recalled that the contents of this sub-field areidentical to the contents of the first device device-ID path field 546shown in FIG. 7). In general, this first “parent” server for thedevice-ID path will not be the same server as for the user-ID path,however, it is possible for these two servers to coincide. As the mannerin which the device private session key is obtained is identical to themanner in which the user private session key is obtained, for ease ofillustration, only the generation and transmission of the user privatesession key is described and illustrated herein.

Referring to FIGS. 1, 2, 3, 4B, 7, 8 and 9, block 224 of the instance ofthe message thread 66 concurrently executing on the processor circuit 51of the second device 28 directs the processor circuit 51 to request userand device private session keys in a similar manner (the discussion ofthe device private session key being omitted for ease of illustration).To request a user private session key, the processor circuit 51 of thesecond device is directed to transmit a signal 570 shown in FIG. 3, tothe first “parent” server identified in the second device user-ID pathfield 544 shown in FIG. 7. In the illustrative example shown in FIG. 1,this first “parent” server is the key server 38. The contents of thesignal 570 are identical to those of the signal 560 shown in FIG. 8. Thesignal 570 is transmitted in a secure manner to the key server 38, via asecure connection established using the key corresponding to the keyserver path information contained in the second device user-ID pathfield 544.

The first “parent” servers, in this example the key servers 36 and 38,proceed to forward the requests for a user private session key to theclosest common user-ID key server, either directly, or via one or moreintermediate key servers (if any) identified along the paths specifiedin the signals 560 and 570. To achieve this, the key server 36 includesthe processor circuit 136, which is configured or programmed by a securecommunications routine including a key server thread 74 similar to thatshown in FIG. 2 in connection with the first device 26. The key serverthread 74 configures the processor circuit 136 of the key server 36 toreceive the request message (i.e., the signal 560) from the first device26 requesting a private key, and to relay the request message to acommon key server potentially accessible by both the first and seconddevices (in this case, the common key server 32). To achieve this, thekey server thread 74 directs the processor circuit 136 to examine thecontents of the first device field 562 of the signal 560, to determinewhether the request message is intended for itself or for its own“parent” key server or a successive parent thereof. If theidentification of the key server 36 is the last server identification inthe first device field 562, then the signal 560 is intended for the keyserver 36; otherwise, if the identification of the key server 36 appearsearlier in the sub-field (as in the present example), the processorcircuit 136 is configured to relay the signal to the next successiveparent key server identified in the first device field 562 of the signal0.560.

Likewise, in this embodiment the key server 38 includes the processorcircuit 138, which is similarly configured to relay the request messagefrom the second device 28 to the common key server 32, in response tothe second device field contents of the signal 570.

In this embodiment, the processor circuits 136 and 138 are configured orprogrammed to respond to such request messages as described herein. Whenthe key server 36 receives the signal 560 from the first device 26, uponrecognizing that the signal 560 is intended for its parent server or asuccessive parent thereof as described above, the processor circuit 136is directed to place the connection with the first device 26 on “pause”,and to transmit a signal 580 to the next successive key serveridentified in the first device field 562 of the signal 560. In theillustrative example shown in FIG. 1, the next successive key server isthe closest common user-ID key server, which in this case is the commonkey server 32. The signal 580 is transmitted from the key server 36 tothe common key server 32 in a secure manner, using a secure Internetconnection between the key servers (more generally, in thisspecification, unless otherwise indicated, all communications among adevice or key server and its “parent” key server are presumed to be viasecure communications channels, as discussed above). The signal 580includes the information contained in the signal 560.

Similarly, when the key server 38 receives the signal 570 from thesecond device 28, the processor circuit 138 is configured to place thesecure connection with the second device on “pause”, and to effectivelyrelay the signal 570, by transmitting a signal 590 to the nextsuccessive key server identified in the second device field of thesignal 570, which in this example is the common key server 32, over asecure communications connection therebetween.

Referring to FIGS. 1, 3 and 10, the common key server 32 includes theprocessor circuit 132, which is configured or programmed by a securecommunications routine including a key server thread 74 similar to thatshown in FIG. 2 in connection with the first device 26. The key serverthread 74 configures the processor circuit 132 to receive such requestmessages from first and second intermediate servers interposed betweenthe common key server and the first and second devices respectively,requesting a private key. The processor circuit 132 is configured togenerate and transmit the private key to the first and secondintermediate servers in response to the request messages, for relay tothe first and second devices. Thus, in the present embodiment, when thecommon key server 32 receives the signals 580 and 590, the processorcircuit 132 of the common key server is configured to first determinewhether the signals are intended for itself, or whether the signals areintended to be relayed to a next successive parent key server. If theidentification of the common key server 32 appears last in the firstdevice field of the signal 580 and in the second device field of thesignal 590, the processor circuit is configured to recognize that thesignals are intended for itself, and is configured to respondaccordingly by generating a private key, which in this embodiment has alength of 8 kilobits. The processor circuit 132 is also directed toproduce a hash value corresponding to the generated private key. In thisembodiment the hash value is produced using the SHA1 hashing algorithm,although alternatively, other hashing algorithms may be substituted. Theprocessor circuit 132 of the common key server 32 then transmits asignal 600 to the key server 36, and transmits an identical signal 610to the key server 38, via the respective secure communicationsconnections established above in connection with the signals 580 and590. As shown in FIG. 10, the signal 600 includes a private session keyfield 602 and a hash value field 604, storing the generated user privatesession key and the hash value, respectively.

The processor circuit 136 of the intermediate key server 36 thenreceives the private key from the common key server and relays theprivate key for receipt by the one of the first and second devices. Moreparticularly, when the key server 36 receives the signal 600, theprocessor circuit 136 is configured to resume the secure connectionbetween itself and the processor circuit 50 of the first device 26 thatwas established in connection with the signal 560. The processor circuit136 of the key server 36 securely transmits, to the first device 26, asignal 620 having contents identical to those of the private session keyfield 602 and the hash value field 604 of the signal 600.

In this embodiment, block 226 then configures the processor circuit 50of the first device 26 to obtain the private key from one of theintermediate key servers that has received the private key from thecommon key server (in this case, from the intermediate key server 36).More particularly, in this embodiment block 226 directs the processorcircuit 50 to receive the signal 620, and to store the received userprivate session key in a user private session key field of the privatekeys register 100 in the RAM 56. As the signal 600 transmitting the userprivate session key from the common key server 32 to the intermediatekey server 36 was secure, as was the signal 620 relaying the key fromthe intermediate key server 36 to the first device, it will beappreciated that the processor circuit 50 is effectively configured toreceive the private key from the common key server via a securecommunications channel.

Block 228 then configures the processor circuit 50 to validate theprivate key relayed to it by the intermediate key server 36. Moreparticularly, block 228 directs the processor circuit 50 to validate theprivate key by receiving a first hash value produced by the common keyserver in response to the private key, generating a second hash value inresponse to the received private key, and comparing the first and secondhash values. More particularly still, block 228 directs the processorcircuit 50 to receive and store the hash value received in the signal620, which was generated by the common key server 32. Block 228 thendirects the processor circuit 50 to generate a hash value in response tothe contents of the user private session key field of the private keysregister 100, using the same hashing algorithm as that used by thecommon key server 32 (in this embodiment, the SHA1 hashing algorithm).Block 228 further directs the processor circuit 50 to compare thegenerated hash value to the hash value received in the signal 620. Anydifference between the generated and received hash values indicates thatthe private key has been corrupted in transit and should not be used.

Similarly, when the key server 38 receives the signal 610, it resumesthe secure connection established between itself and the second device28 that was established in connection with the signal 570. The keyserver 38 then transmits, to the second device, a signal 630 includingthe user private session key and the hash value. Blocks 226 and 228 ofthe instance of the messaging thread 66 that is concurrently executingon the second device 28 direct the processor circuit 51 to store theuser private session key locally thereat, and to perform a hash valueverification as discussed above in connection with the first device.

Thus, when the first device 26 and the second device 28 receive thesignals 620 and 630 respectively, they now have a user private sessionkey that may be used for secure communications between the first andsecond devices. Advantageously, in the present embodiment, thepotentially exploitable security weaknesses associated with asymmetricencryption are avoided by utilizing symmetrical encryption for allsecure communications methods during the establishment of a privatesymmetrical key.

Although the user private session key was transmitted from the commonkey server 32 to the first and second devices 26 and 28 usingsymmetrical encryption methods, in the present embodiment, additionalsecurity enhancements are provided to even further Minimize securityrisks.

Accordingly, to provide such enhancements in this embodiment, aplurality of keys are effectively blended together. In this regard, asnoted the first and second devices 26 and 28 also request and obtain adevice private session key from the closest common device-ID key server,in a manner analogous to that described above in connection with signals560 through 630 in relation to the user private session key. The firstdevice 26 stores the device private session key in a device privatesession key field of the private keys register 100, and the seconddevice 28 also stores the obtained device private session key. Inaddition, it will be recalled that an initial session key was generatedand is stored at each of the first and second devices, as discussedabove in connection with the signal 540 and blocks 220 and 208.

Thus, in this embodiment, blocks 230 to 234 direct each of the processorcircuits 50 and 51 to blend the first and second private keys (i.e., theuser private session key and the device private session key) and theinitial session key to produce a modified key. In this regard, block 230directs the processor circuit 50 to encrypt at least one of the firstand second private keys and the initial session key using at least oneother of the first and second private keys and the initial session key.More particularly, block 230 directs the processor circuit 50 to encryptthe first private key using the second private key to produce aonce-encrypted key. More particularly still, block 230 directs theprocessor circuit 50 to use the device private session key (stored inthe device private session key field of the private keys register 100)to encrypt the user private session key (stored in the user privatesession key field of the private keys register 100), to produce aonce-encrypted key.

In this embodiment, block 232 then directs the processor circuit 50 toencrypt the once-encrypted key using the initial session key (stored inthe initial session key register 98) to produce a twice-encrypted key.The twice-encrypted key is stored in the blended key register 102.

Block 234 then directs the processor circuit 50 to generate a hash valuein response to the twice-encrypted key, and append the hash value to thetwice-encrypted key. More particularly, the processor circuit isdirected to calculate a hash value of the twice-encrypted key, using theSHA1 hashing algorithm. The processor circuit is then directed to appendthe hash value to the end of the twice-encrypted key.

Block 234 further directs the processor circuit 50 to delete a portionof the twice-encrypted key other than the hash value appended thereto,the deleted portion having a length equal to the hash value appendedthereto. More particularly, the processor circuit is directed to delete,from the beginning of the twice-encrypted key, a length equal to thelength of the hash value it has just appended to the end of the key,thereby restoring the key to its original length.

Block 234 then directs the processor circuit 50 to repeat the steps ofgenerating and appending a hash value to the twice-encrypted key anddeleting a portion of the twice-encrypted key until the twice-encryptedkey has been entirely replaced with appended hash values. Moreparticularly, the processor circuit is directed to take the resultingmodified key resulting from the above steps of appending and deleting,and to repeat the above hashing, appending and deleting steps, aplurality of times. In this embodiment, these steps are performed 52times, at the end of which the entire original twice-encrypted key willhave been completely deleted and replaced with appended hash values. Theresult, following such repetition of this hashing procedure, is a final,private session key, that may be used in establishing a securecommunications connection between the first and second devices 26 and28. Block 236 directs the processor circuit 50 to store this key in thefinal private session key register 104.

Similarly, blocks 230 through 236 of the concurrently executingmessaging thread 66 on the second device 28 direct the processor circuit51 to perform identical blending and hashing procedures, to generate andstore a final private session key identical to that generated and storedin the final private session key register 104 of the first device 26.

Thus, the final private session key so generated is a truly private key,with no corresponding root keys stored in a software program or on thedevice or on a publicly accessible key server. As the final privatesession key has not been directly transmitted over the Internet at all,and no devices other than the first and second devices have all the datanecessary to create the final private session key, security isconsiderably enhanced as compared to conventional secure communicationssystems. In addition, in the present example, the final private sessionkey was obtained by first and second devices that did not share anyimmediate parent key server in common (i.e., there was no single serverwith which both the first and second devices had previously exchangedkeys to enable secure communication therebetween). The common key server32 was identified automatically by the processor circuits 50 and 51under the directionof the messaging thread 66, without requiring theusers of the first and second devices to have any advance knowledge ofeach other's key servers (or indeed, of their own key servers).

Once such a final private session key has been obtained by both thefirst and second devices 26 and 28 in the above manner, securecommunications therebetween may be carried out. For example, the firstdevice 26 may transmit a signal 650 to the second device 28, and thesecond device may transmit a signal 640 to the first device 26, bothsuch signals being encrypted in response to the final private sessionkey. If either such signal is received before the receiving device hasfinished producing the final private session key, the informationencoded in the signal may be simply stored in a buffer until therequired key has been produced.

In the present embodiment, such encrypted communications are handled bythe various other threads of the secure communications routine 62, asdiscussed in greater detail below. Alternatively, however, numerousother ways of implementing secure communications between the first andsecond devices using the final private session key would be apparent toone of ordinary skill in the art upon reviewing this specification. Ingeneral, any suitable encryption method may be employed.

However, a particularly advantageous encryption method, employing amodified ARC4 streaming cipher encryption method with session control,is briefly described for illustrative purposes.

Encryption/Decryption Thread

Referring back to FIG. 2, in the present embodiment, theencryption/decryption thread 68 co-operates with the various otherthreads (described briefly below) of the secure communications routine62 to configure the processor circuits 50 and 51 to encryptcommunications between the first and second devices in response to theprivate key. More particularly, each processor circuit is configured toencrypt communications using a blended key produced in response to theprivate key. More particularly still, such encryption occurs using thefinal private session key produced in response to the first and secondprivate keys and the initial session key (stored in the final privatesession key register 104). For ease of illustration, only the processorcircuit 50 of the first device 26 is described, it being understood thatthe processor circuit 51 of the second device 28 is similarlyconfigured.

In this embodiment, the encryption/decryption thread 68 configures theprocessor circuit 50 to initiate a cipher communications session usingthe blended key described above. More particularly, the processorcircuit is configured to use the final private session key stored in thefinal private session key register 104, to initiate and execute amodified ARC4 streaming cipher communications session, thecommunications stream including session control information, key serverinformation, and user data.

In this embodiment, the encryption/decryption thread 68 directs theprocessor circuit 50 to determine whether outgoing data has been placedin either the send buffer 110 or the key send buffer 112 for encryptionand transmission to the second device. If so, the processor circuit isdirected to encrypt up to one 64 kB block of data in accordance with themodified ARC4 algorithm described below, and to append a header to theencrypted block, the header including the length of the block, a dataverification value produced in response to the length, and a flagindicative of whether the block represents user data from the sendbuffer 110 or key data from the key send buffer 112. Similarly, theencryption/decryption thread 68 directs the processor circuit to decryptreceived data that has been placed in the pipe receive global buffer 118under the direction of the pipe control/TCP send thread 70, bydecrypting such data according to the modified ARC4 algorithm describedbelow, and storing the decrypted data in either the receive buffer 122or the key receive buffer 120, depending on whether the header flagindicates user data or key data, respectively.

In the present embodiment, the encryption/decryption thread 68 includesa number of modifications to the conventional ARC4 method. It will beappreciated that the conventional ARC4 method involves use of an arrayproduced in response to the relevant key, referred to as an S-array, toencrypt communications. The conventional ARC4 method is designed to use2 kilobit keys, whereas the present embodiment of the invention employs8 kilobit or 1 kiloByte keys. Accordingly, in this embodiment the ARC4algorithm is modified to accommodate the larger key size of the finalprivate session key, and the corresponding larger size of the S-array.For example, in the initialization and definition of the S-array, andthe temporary K-array used to assist in this initialization anddefinition process, the modulus or remainder operator is changed fromMOD 256 to MOD 1024. Similarly, many of the For-Next loop indices areranged from 0 to 1023 rather than 0 to 255. Further necessarymodifications in this regard will be readily apparent to one of ordinaryskill in the art upon review of the instructions disclosed herein.

In addition, in the present embodiment, during the initial definition ofthe S-array, the conventional ARC4 algorithm includes a swapping orshuffling loop, whereby each entry in the S-array is swapped with oneother entry in the S-array. The conventional ARC4 algorithm executesthis swapping loop once. However, in the present embodiment, in which alarger S-array is employed, the processor circuit 50 is configured torepeat the shuffling loop of the ARC4 streaming cipher communicationssession, a prime number of times greater than two. For example, in thisembodiment the shuffling or swapping loop is repeated 13 times, toreduce the statistical likelihood that the repeated swapping may tend torestore the array to a configuration closer to its originalconfiguration.

In this embodiment, both the first and second devices are configured orprogrammed to generate the S-array in the same way. Accordingly, as theywill both begin with an identical final private session key, they willboth arrive at the same initial S-array, with which to commenceencrypted communications.

Once the S-array has been initialized and generated in this manner, itmay then be used by the “inner loop” of the ARC4 algorithm to encryptcommunications between the first and second devices. It will beappreciated that the ARC4 streaming cipher effectively modifies theencryption key each time a new character is encrypted. In thisembodiment, the inner loop of the ARC4 algorithm is re-written inassembler language, for faster processing. In this embodiment, themodified inner loop of the ARC4 algorithm includes four main steps forencrypting each successive character. First, a looping counter i rangingfrom 0 to 1023 is incremented (resetting to 0 after 1023). Second, arandom location of the S-array is selected, by setting a valuej_(current)=[j_(previous)+S(i)]MOD1024. Third, the contents of twolocations of the S-array, namely, S(i) and S(j), are swapped. Fourth, amixing value is selected, by taking a value [S(i)+S(j)]MOD1024, usingthis value as an array location index to look up a value stored in theS-array, or in other words, S([S(i)+(j)]MOD1024), taking the modulus orremainder operator 256 of this value, or in other words,S([S(i)+S(j)]MOD1024)MOD256, and performing an exclusive OR operation onthe current character and this latter value, to yield (encryptedcharacter)=(current character)XOR[S([S(i)+S(j)]MOD1024)MOD256]. It willbe appreciated that this latter step is a further modification of theconventional ARC4 algorithm, which performs the XOR operation using[S([S(i)+S(j)]MOD256)] rather than [S([S(i)+S(j)]MOD1024)MOD256].

Additionally, in this embodiment, the values used by the inner loop ofthe modified ARC4 algorithm, including the entire S-array and thecounter indices i and j, are saved following encryption of each block ofdata, so that when the next block of data is to be encrypted in the samesession, the previously saved S-array and counter values are used.Therefore, in this embodiment, the S-array does not have to bere-initialized following encryption of each block of data. Rather, theencryption proceeds continuously throughout the entire communicationssession between the first and second devices. Effectively, the entirecommunications session, which may involve transmission of a large numberof data blocks (which in this embodiment are 64 kB blocks), is treatedas if it were a single block for the purpose of the changing encryptionkey value, as the encryption key is never re-initialized during thesession.

As noted, the data stream encrypted using the modified ARC4 algorithm asdescribed above includes session control information, key serverinformation, and user data. In this embodiment, the session controlvalue is a calculated value that changes according to pre-defined rulesover successive time periods. For example, the session control value maybe changed every 5 seconds, and may be changed according to a seededpseudo-random number generation scheme, or any suitable alternativemethod. When the session is first established, one of the first andsecond devices transmits an initial session control value to the otherdevice. Each of the first and second devices calculates a next expectedsession control value, that it expects to receive from the other deviceduring the next successive time period. Periodically (e.g., once pertime period), each device checks the session control value presentlyreceived from the other device, and if the received session controlvalue is not equal to the expected session control value, the deviceterminates the communications session with the other device.

In this embodiment, a data verification value is produced for each datablock and is appended to the data block before the data block isencrypted. In this embodiment, each data block has a size of 64 kB. Inthis regard, although conventional methods such as the SHA1 hashingalgorithm could conceivably be used to produce hash values to act asdata verification values for the various data blocks, the SHA1 algorithmtends to entail an undesirably large amount of overhead for use on everydata block to be transmitted and received. In addition, the level ofsecurity required for the data verification value is lessened in thepresent embodiment, due to the fact that the data verification value isencrypted along with the data block. Accordingly, in this embodiment analternative data verification value is produced, as follows. To producethe data verification value for a data string having a length L, thedata verification value, which has 4 bytes, is initially set to zero.Then, for each character in the data string, a specific successive byteof the data verification value is modified: the first byte is modifiedfor the first, fifth, ninth, etc. characters of the data string, thesecond byte is modified for the second, sixth, tenth, etc. characters.For illustrative notational purposes, if the four bytes are labelledbyte#0, byte#1, byte#2 and byte#3, and the character location of eachcharacter in the data string is denoted by x (0≦x≦(L−1)), then for thex^(th) character, byte#(xMOD4) is modified. The identified byte of thedata verification value is first subjected to an XOR operation with the((L−1)−x)^(th) character of the data string (for example, for the firstcharacter at location x=0, byte#0 of the data verification value isXOR'd with the last or (L−1)^(th) character of the data string.) Theresulting value is then subjected to an XOR operation with xMOD256. Thisis repeated for each of the L values of the data string, to arrive atthe final data verification value for the data string.

Other Threads

It will be recalled that in the present embodiment, the userapplications 64 do not interface directly with the TCP/IP functionalityof the operating system 60. Rather, the user applications 64 interfacewith the secure communications routine 62, which is provided in the formof a dynamic link library (.dll) file, and which establishes and handlesall TCP/IP communications.

Generally, the TCP receive thread 72 directs the processor circuit 50 tocontinuously poll an operating system TCP receive buffer and appendblocks of any received data to the pipeline control buffer 116, checkingfor TCP errors and appending errors.

In this embodiment, the pipe contro/TCP send thread 70 generally directsthe processor circuit 50 to both transmit and assist in receiving data.For example, the pipe control/TCP send thread directs the processorcircuit to check whether any outgoing data has been placed in the globalpipe send buffer 114. If so, the processor circuit is directed to removeup to one 64 kB block of such data, to append a header to the block (inthis embodiment the header includes a length of the block, a dataverification value produced in response to the length, and a data flagindicating whether the block represents session control information oruser data), to store the block in a local send buffer (not shown), andto invoke an operating system TCP send function to transmit the block tothe second device. The pipe control/TCP send thread 70 also directs theprocessor circuit 50 to periodically calculate a new session controlvalue (as discussed above in connection with the encryption/decryptionthread 68), for each new successive time period of the session, and totransmit the session control value to the second device in a similarmanner. The pipe control/TCP send thread 70 also assists in receivingdata, by directing the processor circuit to determine whether data hasbeen placed in the pipeline control buffer 116 under the direction ofthe TCP receive thread 72, and if so, to parse the received data intodata blocks. If the received data is session control information, theprocessor circuit is directed to compare the received session controlvalue to the expected value, and to terminate the session with thesecond device if they are not equal, as discussed above. If the receiveddata is user data (as indicated by a flag in the header), the processorcircuit is directed to store the received data blocks in the pipereceive global buffer 118. The pipe control/TCP send thread 70 alsodirects the processor circuit to terminate the session with the seconddevice if no session control value has been received in a time periodexceeding a threshold timeout value.

In the present embodiment, the data object monitor thread 76 configuresthe processor circuit 50 to provide cross-object statisticalinformation, including global error notification, within the securecommunications layer, the applications layer, and optionally to the enduser if the communications layer is running in debug mode. Also in thisembodiment, the data object monitor thread configures the processorcircuit to clear deadlocks that could potentially occur in the globalmemory registers, clean up locks on global memory registers that mayhave timed out, and perform memory management operations (e.g. garbagecollection) when an object is destroyed.

In this embodiment, the key server thread 74 is included in the securecommunications routine 62, to allow the processor circuit 50 to functionas a key server, including performing the functions of the intermediatekey server 36 and the common key server 32 as described earlier herein,for example. In this embodiment, the messaging thread 66 cooperates withthe key server thread 74 to configure the processor circuit 50 toprocess key management tasks for both client operations and serveroperations. In turn, the key server thread 74 cooperates with themessaging thread 66 and its associated threads to configure theprocessor circuit to perform the actual sending and receiving of thedata (it will be recalled that in the present embodiment, the pipecontrol/TCP thread identifies transmitted data as user data (applicationdata,) control data (pipe control data), or the key data (key serverthread data). The cooperation of the threads to achieve suchfunctionality tends to significantly reduce the size of the securecommunications routine 62 and its complexity as duplication ofprogramming logic is avoided.

In the present embodiment, the threadsafe function 80 includessub-functions that allow the processor circuit 50, under the directionof a particular thread, to lock or unlock the contents of a data field,to copy the contents of a data field, to remove or cut the contents of adata field, to put data into a field replacing its former contents, toremove only a single block of data from a field on a first-in-first-outbasis, to append data to a buffer, to initialize a buffer size, andother similar data management functions. The threadsafe function 80cooperates with the data object monitor thread 76 discussed above toachieve such functionality.

Alternatively, however, other suitable delineations of functionalityamong the various threads may be substituted. More generally, any othersuitable way of causing a processor circuit or equivalent device toperform the functions herein may be substituted without departing fromthe scope of the present invention.

More generally still, while specific embodiments of the invention havebeen described and illustrated, such embodiments should be consideredillustrative of the invention only and not as limiting the invention asconstrued in accordance with the accompanying claims.

1. A method of facilitating secure communication between first andsecond devices, the method comprising: automatically identifying acommon key server potentially accessible by both the first and seconddevices; and obtaining a secure private key from the common key server,for use in encrypting communications between the first and seconddevices.
 2. The method of claim 1 wherein identifying comprisestransmitting identifications of key servers from one of the first andsecond devices to the other of the first and second devices.
 3. Themethod of claim 2 wherein identifying further comprises producing afirst list of key servers potentially accessible by the first device. 4.The method of claim 3 wherein producing comprises including in the firstlist, identifications of key servers associated with first device keysstored in a storage medium of the first device.
 5. The method of claim 4wherein producing further comprises including in the first list,identifications of intermediate key servers interposed along securecommunications paths between each of the key servers associated with thefirst device keys and a master key server.
 6. The method of claim 3wherein transmitting comprises transmitting the first list from thefirst device to the second device.
 7. The method of claim 6 whereinidentifying further comprises receiving at the first device, from thesecond device, an identification of the common key server.
 8. The methodof claim 2 wherein identifying further comprises receiving at 4 thesecond device, a first list of key servers potentially accessible by thefirst device.
 9. The method of claim 8 wherein identifying furthercomprises producing a second list of key servers potentially accessibleby the second device.
 10. The method of claim 9 wherein producingcomprises including in the second list, identifications of key serversassociated with second device keys stored in a storage medium of thesecond device.
 11. The method of claim 10 wherein producing furthercomprises including in the second list, identifications of intermediatekey servers interposed along secure communications paths between each ofthe key servers associated with the second device keys and a master keyserver.
 12. The method of claim 9 wherein identifying further comprisescomparing the first and second lists, and identifying, as the common keyserver, a key server identified in both lists.
 13. The method of claim12 wherein identifying comprises identifying as the common key server,from among a group of key servers each of which is identified in boththe first and second lists, the key server having the shortestcommunications paths to the first and second devices.
 14. The method ofclaim 1 wherein identifying comprises identifying as the common keyserver, a key server at an intersection of a first communication pathdefined between a first key server having a previously establishedrelationship with the first device and a master key server, and a secondcommunication path defined between a second key server having apreviously established relationship with the second device and themaster key server.
 15. The method of claim 12 wherein transmittingcomprises transmitting, from the second device to the first device, anidentification of the common key server.
 16. The method of claim 15wherein transmitting further comprises transmitting, from the seconddevice to the first device, identifications of any intermediate keyservers interposed between the first device and the common key server.17. The method of claim 1 wherein identifying further comprisesidentifying intermediate key servers interposed along a communicationspath between one of the first and second devices and the common keyserver.
 18. The method of claim 17 wherein obtaining comprises obtainingthe private key from one of the intermediate key servers that hasreceived the private key from the common key server.
 19. The method ofclaim 1 wherein obtaining comprises receiving the private key from thecommon key server via a secure communications channel.
 20. The method ofclaim 19 wherein receiving comprises receiving the private key from anintermediate key server that has received the private key from thecommon key server.
 21. The method of claim 19 wherein obtaining furthercomprises transmitting a request message to the common key server torequest the common key server to transmit the private key.
 22. Themethod of claim 21 wherein transmitting comprises transmitting therequest message to an intermediate key server, for relay to the commonkey server.
 23. The method of claim 19 further comprising validating theprivate key.
 24. The method of claim 23 wherein validating comprisesreceiving a first hash value produced by the common key server inresponse to the private key, generating a second hash value in responseto the received private key, and comparing the first and second hashvalues.
 25. The method of claim 1 wherein obtaining comprises obtainingfirst and second private keys from at least one of the common key serverand a second common key server potentially accessible by both the firstand second devices.
 26. The method of claim 25 wherein obtaining firstand second private keys comprises obtaining a private user key from acommon user key server and a private device key from a common device keyserver.
 27. The method of claim 25 further comprising obtaining aninitial session key.
 28. The method of claim 27 wherein obtaining theinitial session key comprises receiving the initial session key at thefirst device.
 29. The method of claim 27 wherein obtaining the initialsession key comprises generating the initial session key at the seconddevice and transmitting the initial session key to the first device. 30.The method of claim 1 further comprising encrypting communicationsbetween the first and second devices, in response to the private key.31. The method of claim 25 further comprising encrypting communicationsbetween the first and second devices, in response to the first andsecond private keys.
 32. The method of claim 27 further comprisingencrypting communications between the first and second devices, inresponse to the first and second private keys and the initial sessionkey.
 33. The method of claim 32 wherein encrypting comprises blendingthe first and second private keys and the initial session key to producea modified key.
 34. The method of claim 33 wherein blending comprisesencrypting at least one of the first and second private keys and theinitial session key using at least one other of the first and secondprivate keys and the initial session key.
 35. The method of claim 33wherein blending comprises encrypting the first private key using thesecond private key to produce a once-encrypted key.
 36. The method ofclaim 35 wherein blending further comprises encrypting theonce-encrypted key using the initial session key to produce atwice-encrypted key.
 37. The method of claim 36 wherein blending furthercomprises generating a hash value in response to the twice-encryptedkey, and appending the hash value to the twice-encrypted key.
 38. Themethod of claim 37 wherein blending further comprises deleting a portionof the twice-encrypted key other than the hash value appended thereto,the deleted portion having a length equal to the hash value appendedthereto.
 39. The method of claim 38 wherein blending further comprisesrepeating the steps of generating and appending a hash value to thetwice-encrypted key and deleting a portion of the twice-encrypted keyuntil the twice-encrypted key has been entirely replaced with appendedhash values.
 40. The method of claim 30 wherein encrypting comprisesencrypting communications between the first and second devices using ablended key produced in response to the private key.
 41. The method ofclaim 40 wherein encrypting comprises initiating a cipher communicationssession with the blended key.
 42. The method of claim 41 whereininitiating comprises executing a modified ARC4 streaming ciphercommunications session.
 43. The method of claim 42 wherein executingcomprises repeating a shuffling loop of the ARC4 streaming ciphercommunications session, a prime number of times greater than two. 44.(canceled).
 45. (canceled).
 46. A computer-readable medium storing codesegments for directing a processor circuit to carry out the method ofclaim
 1. 47. A signal embodied in a communications medium, the signalcomprising code segments for directing a processor circuit to carry outthe method of claim
 1. 48. A signal embodied in a carrier wave, thesignal comprising code segments for directing a processor circuit tocarry out the method of claim
 1. 49. An apparatus for facilitatingsecure communication between first and second devices, the apparatuscomprising: a processor circuit capable of communication with a network,the processor circuit configured to identify a common key serverpotentially accessible by both the first and second devices; wherein theprocessor circuit is configured to obtain a secure private key from thecommon key server, for use in encrypting communications between thefirst and second devices.
 50. The apparatus of claim 49 wherein theprocessor circuit is configured to transmit identifications of keyservers from one of the first and second devices to the other of thefirst and second devices.
 51. The apparatus of claim 50 wherein theprocessor circuit is configured to produce a first list of key serverspotentially accessible by the first device.
 52. The apparatus of claim51 wherein the processor circuit is configured to include in the firstlist, identifications of key servers associated with first device keysstored in a storage medium of the first device.
 53. The apparatus ofclaim 52 wherein the processor circuit is configured to include in thefirst list, identifications of intermediate key servers interposed alongsecure communications paths between each of the key servers associatedwith the first device keys and a master key server.
 54. The apparatus ofclaim 51 wherein the processor circuit is configured to transmit thefirst list from the first device to the second device.
 55. The apparatusof claim 54 wherein the processor circuit is configured to receive atthe first device, from the second device, an identification of thecommon key server.
 56. The apparatus of claim 50 wherein the processorcircuit is configured to receive at the second device, a first list ofkey servers potentially accessible by the first device.
 57. Theapparatus of claim 56 wherein the processor circuit is configured toproduce a second list of key servers potentially accessible by thesecond device.
 58. The apparatus of claim 57 wherein the processorcircuit is configured to include in the second list, identifications ofkey servers associated with second device keys stored in a storagemedium of the second device.
 59. The apparatus of claim 58 wherein theprocessor circuit is configured to include in the second list,identifications of intermediate key servers interposed along securecommunications paths between each of the key servers associated with thesecond device keys and a master key server.
 60. The apparatus of claim57 wherein the processor circuit is configured to compare the first andsecond lists, and identify, as the common key server, a key serveridentified in both lists.
 61. The apparatus of claim 60 wherein theprocessor circuit is configured to identify as the common key server,from among a group of key servers each of which is identified in boththe first and second lists, the key server having the shortestcommunications paths to the first and second devices.
 62. The apparatusof claim 49 wherein the processor circuit is configured to identify asthe common key server, a key server at an intersection of a firstcommunication path defined between a first key server having apreviously established relationship with the first device and a masterkey server, and a second communication path defined between a second keyserver having a previously established relationship with the seconddevice and the master key server.
 63. The apparatus of claim 60 whereinthe processor circuit is configured to transmit, from the second deviceto the first device, an identification of the common key server.
 64. Theapparatus of claim 63 wherein the processor circuit is configured totransmit, from the second device to the first device, identifications ofany intermediate key servers interposed between the first device and thecommon key server.
 65. The apparatus of claim 49 wherein the processorcircuit is configured to identify intermediate key servers interposedalong a communications path between one of the first and second devicesand the common key server.
 66. The apparatus of claim 65 wherein theprocessor circuit is configured to obtain the private key from one ofthe intermediate key servers that has received the private key from thecommon key server.
 67. The apparatus of claim 49 wherein the processorcircuit is configured to receive the private key from the common keyserver via a secure communications channel.
 68. The apparatus of claim67 wherein the processor circuit is configured to receive the privatekey from an intermediate key server that has received the private keyfrom the common key server.
 69. The apparatus of claim 67 wherein theprocessor circuit is configured to transmit a request message to thecommon key server to request the common key server to transmit theprivate key.
 70. The apparatus of claim 69 wherein the processor circuitis configured to transmit the request message to an intermediate keyserver, for relay to the common key server.
 71. The apparatus of claim67 the processor circuit is configured to validate the private key. 72.The apparatus of claim 71 wherein the processor circuit is configured tovalidate the private key by receiving a first hash value produced by thecommon key server in response to the private key, generating a secondhash value in response to the received private key, and comparing thefirst and second hash values.
 73. The apparatus of claim 49 wherein theprocessor circuit is configured to obtain first and second private keysfrom at least one of the common key server and a second common keyserver potentially accessible by both the first and second devices. 74.The apparatus of claim 73 wherein the processor circuit is configured toobtain, as the first and second private keys, a private user key from acommon user key server and a private device key from a common device keyserver.
 75. The apparatus of claim 73 wherein the processor circuit isconfigured to obtain an initial session key.
 76. The apparatus of claim75 wherein the processor circuit is configured to receive the initialsession key at the first device.
 77. The apparatus of claim 75 whereinthe processor circuit is configured to generate the initial session keyat the second device and transmit the initial session key to the firstdevice.
 78. The apparatus of claim 49 wherein the processor circuit isconfigured to encrypt communications between the first and seconddevices, in response to the private key.
 79. The apparatus of claim 73wherein the processor circuit is configured to encrypt communicationsbetween the first and second devices, in response to the first andsecond private keys.
 80. The apparatus of claim 75 wherein the processorcircuit is configured to encrypt communications between the first andsecond devices, in response to the first and second private keys and theinitial session key.
 81. The apparatus of claim 80 wherein the processorcircuit is configured to blend the first and second private keys and theinitial session key to produce a modified key.
 82. The apparatus ofclaim 81 wherein the processor circuit is configured to encrypt at leastone of the first and second private keys and the initial session keyusing at least one other of the first and second private keys and theinitial session key.
 83. The apparatus of claim 81 wherein the processorcircuit is configured to encrypt the first private key using the secondprivate key to produce a once-encrypted key.
 84. The apparatus of claim83 wherein the processor circuit is configured to encrypt theonce-encrypted key using the initial session key to produce atwice-encrypted key.
 85. The apparatus of claim 84 wherein the processorcircuit is configured to generate a hash value in response to thetwice-encrypted key, and append the hash value to the twice-encryptedkey.
 86. The apparatus of claim 85 wherein the processor circuit isconfigured to delete a portion of the twice-encrypted key other than thehash value appended thereto, the deleted portion having a length equalto the hash value appended thereto.
 87. The apparatus of claim 86wherein the processor circuit is configured to repeat the steps ofgenerating and appending a hash value to the twice-encrypted key anddeleting a portion of the twice-encrypted key until the twice-encryptedkey has been entirely replaced with appended hash values.
 88. Theapparatus of claim 78 wherein the processor circuit is configured toencrypt communications between the first and second devices using ablended key produced in response to the private key.
 89. The apparatusof claim 88 wherein the processor circuit is configured to initiate acipher communications session with the blended key.
 90. The apparatus ofclaim 89 wherein the processor circuit is configured to execute amodified ARC4 streaming cipher communications session.
 91. The apparatusof claim 90 wherein the processor circuit is configured to repeat ashuffling loop of the ARC4 streaming cipher communications session, aprime number of times greater than two.
 92. An apparatus forfacilitating secure communication between first and second devices, theapparatus comprising: means for identifying a common key serverpotentially accessible by both the first and second devices; and meansfor obtaining a secure private key from the common key server, for usein encrypting communications between the first and second devices.
 93. Amethod of facilitating secure communications between first and seconddevices, the method comprising: receiving, at an intermediate keyserver, a request message from one of the first and second devicesrequesting a private key; and relaying the request message to a commonkey server potentially accessible by both the first and second devices.94. The method of claim 93 further comprising receiving the private keyfrom the common key server and relaying the private key for receipt bythe one of the first and second devices.
 95. (canceled).
 96. (canceled).97. A computer-readable medium storing code segments for directing aprocessor circuit to carry out the method of claim
 93. 98. A signalembodied in a communications medium, the signal comprising code segmentsfor directing a processor circuit to carry out the method of claim 93.99. A signal embodied in a carrier wave, the signal comprising codesegments for directing a processor circuit to carry out the method ofclaim
 93. 100. An apparatus for facilitating secure communicationsbetween first and second devices, the apparatus comprising: anintermediate key server comprising a processor circuit configured toreceive a request message from one of the first and second devicesrequesting a private key; wherein the processor circuit is configured torelay the request message to a common key server potentially accessibleby both the first and second devices.
 101. An apparatus for facilitatingsecure communications between first and second devices, the apparatuscomprising: an intermediate key server comprising: means for receiving arequest message from one of the first and second devices requesting aprivate key; and means for relaying the request message to a common keyserver potentially accessible by both the first and second devices. 102.A method of facilitating secure communications between first and seconddevices, the method comprising: receiving, at a common key serverpotentially accessible by both the first and second devices, requestmessages from first and second intermediate servers interposed betweenthe common key server and the first and second devices respectively,requesting a private key; and generating and transmitting the privatekey to the first and second intermediate servers in response to therequest messages, for relay to the first and second devices. 103.(canceled).
 104. (canceled).
 105. A computer-readable medium storingcode segments for directing a processor circuit to carry out the methodof claim
 102. 106. A signal embodied in a communications medium, thesignal comprising code segments for directing a processor circuit tocarry out the method of claim
 102. 107. A signal embodied in a carrierwave, the signal comprising code segments for directing a processorcircuit to carry out the method of claim
 102. 108. An apparatus forfacilitating secure communications between first and second devices, theapparatus comprising: a common key server potentially accessible by boththe first and second devices, the common key server comprising aprocessor circuit configured to receive request messages from first andsecond intermediate servers interposed between the common key server andthe first and second devices respectively, requesting a private key;wherein the processor circuit is configured to generate and transmit theprivate key to the first and second intermediate servers in response tothe request messages, for relay to the first and second devices.
 109. Anapparatus for facilitating secure communications between first andsecond devices, the apparatus comprising: a common key serverpotentially accessible by both the first and second devices, the commonkey server comprising: means for receiving request messages from firstand second intermediate servers interposed between the common key serverand the first and second devices respectively, requesting a private key;and means for generating and transmitting the private key to the firstand second intermediate servers in response to the request messages, forrelay to the first and second devices.